There exist commercial endeavors in which a plurality of computer applications share a set of entities or subjects which are common to the applications. For example, in the field of medicine, a user may provide input describing a given patient to multiple applications. The input may be clinical information, such as x-ray images or blood work results, financial information, such as insurance coverage or billing history, or other types of information. The user's task historically entailed repeating the entry of data identifying the patient into the multiple applications. Although patient data is an illustrative example, this practice extends to data describing other subjects as well, such as a user (i.e., to enable “single sign-on,” wherein a user logs in to a single network-based resource and is automatically given access to other authorized network-based resources), patient encounter, clinical provider, observation, insurer, or other subject. The use of shared information among multiple applications is not limited to the medical field.
Data which describes a given subject, and which is used commonly by a plurality of applications, is referred to herein as a “context” defined by that subject. The desirability of managing context in the healthcare industry, so that a user need not repeatedly enter information for a subject into multiple applications, has been recognized. To this end, a standard for context management, known as the Health Level 7 (HL7) context management specification, was published in 1999 by the Clinical Context Object Workgroup (CCOW). The CCOW standard defines a context management architecture (CMA) and processes for managing information describing a subject across a range of clinical and other healthcare-related applications.
Among other features, the CCOW standard defines interfaces for inter-process communication, including communication between applications and a software-based module which coordinates the modification of data across applications (the “context manager”). One embodiment of a context manager is described in commonly-assigned U.S. patent application Ser. No. 09/545,396, which is incorporated herein by reference.
The interfaces (“technology mappings”) defined by CCOW provide for communication between the context manager and various “styles” of applications, including those which follow the Microsoft Common Object Model (COM) and Hypertext Transport Protocol (HTTP) conventions, among others. For example, for a COM-based application, the CCOW standard specifies COM interfaces which allow the COM-based application to exchange data and parameters with the context manager when using a CCOW compliant context management system. The interfaces may be programmed to process COM-based data and parameters provided by the context manager and context participant applications to support the context management functions.
FIG. 1 depicts an exemplary context management system, in which a context manager 230 manages context for two context participant applications 210 and 220. Applications 210 and 220 may execute on the same or separate computers, and the computer(s) may be the same or separate from a computer on which context manager 230 executes. Communication between the processes may be enabled via any of numerous combinations of protocols and physical communications devices or components. For example, when the applications 210, 220 and/or the context manager 230 execute on the different computers interconnect by a network (e.g., a local area network), the TCP/IP protocol may be employed.
According to the CCOW standard, communication between the applications in a context and the context manager is facilitated through the use of context participant (CP) interfaces for the applications and a set of context manager (CM) interfaces for the context manager. Each of the CP and CM interfaces may comprise any of numerous suitable components for enabling inter-process communication. In one embodiment, each of the CP and CM interfaces is integrated in an associated application and provides a “plug” which enables communication with the application (e.g., CP interfaces 217, 227 may be implemented within applications 210, 220 respectively, and CM interface 235 may be implemented in an application program executing on the computer on which the context manager 230 executes). In the illustrative system of FIG. 1, the applications 210, 220 have CP interfaces 217, 227, respectively, associated with them.
Context participant (CP) interfaces 217 and 227, respectively, receive communications from context manager 230 on behalf of applications 210, 220. Applications 210, 220 may receive communications from the context manager 230 in a format and style commensurate with the CCOW standard (e.g., as COM messages or HTTP encoded messages over TCP/IP). In the embodiment shown, the communications pass through code portions 214 and 224 associated with the applications. CP interfaces 217, 227 may alternatively be incorporated directly into applications 210, 220 as described above, and directly pass communications thereto. As a further alternative, a CP wrapper or bridge can be provided that performs the function of the CP interface 217, 227, and allows an application to communicate according to the CCOW standard, without requiring any modification of the application itself. Context manager (CM) interface 235 receives communications from applications 210 and 220 and forwards those communications to the context manager 230.
As mentioned above, each of applications 210 and 220 includes a series of programmed routines integrated with the respective application code to perform context management support functions as defined by the CCOW standard. For example, applications 210 and 220 include code portions enabling communication with the context manager. Specifically, within application 210, code portion 212 defines messages sent to the CM interface 235, and code portion 214 implements the CP interface 217. Similarly, application 220 includes code portions 222 and 224 that, respectively, perform the same functions as code portions 212 and 214.
When a user of one of the applications (e.g., application 210) desires to switch the context by changing the data for a subject (e.g., switching from one patient to another), the application sends a request to the context manager 230 (via CM interface 235). The requesting application is referred to as an “instigator” of the requested change in the context.
When the context manager receives a request to change a subject of the context, context manager 230 surveys the other applications in the context (e.g., application 220), to determine whether the switch is acceptable to them. The context manager 230 performs the survey by sending a request to the other applications (e.g., application 220) via their associated CP interfaces. The other applications in the context may determine whether the subject change is acceptable or conditionally acceptable. While rules defining the acceptability of a subject change may be customized for specific applications and contexts, an example of a situation where a requested change may be conditionally acceptable is if data relating to the existing subject has not yet been written to permanent memory on the computer on which the application executes. In this example, the other application may respond to the survey by alerting the instigator that the data could be lost if a change proceeded. The surveyed applications respond to the survey by transmitting messages back to the context manager 230 describing their reactions to the requested change.
According to the CCOW standard, the context manager 230 communicates the results of the survey to the instigator application, and a user thereof examines the results and determines how to proceed. There are a range of options that the user can select, including canceling the requested change, executing the requested change, or removing the instigator application from the context. Any of these options can be selected by the user irrespective of the results of the survey. For example, if one or more of the surveyed applications indicates that the requested change is unacceptable to it, the instigator application may nevertheless force the context change, or alternatively, may simply remove itself from the context so that the instigator application can implement whatever changes it desires without impacting the other applications in the context. After the user decides how to proceed with the requested change, a call is made by the instigator application to the context manager 230 informing the context manager of the change decision. The context manager then makes one or more calls to publish the change decision by notifying the other applications in the context of the decision.
While CCOW supports context sharing among a number of different types of applications such as COM-based applications, HTTP or web-based applications, applications executed on a remote server and emulated on a client (e.g., using the Citrix MetaFrame and ICA client architecture), and others, CCOW does not define any implementation for enabling applications of different types to communicate in a manner that facilitates context sharing. In addition, in the example discussed above in connection with FIG. 1, it is assumed that communications can flow freely between the context manager and the computers on which the applications in the context are executing. However, in many networked environments that have security measures in place, that is not the case.
Various embodiments of the present invention are directed to techniques for performing context management in a networked environment.